NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/cbm/4393

Internet Message Format | 1996-08-05 | 4.1 KB

Path: seagoon.newcastle.edu.au!usenet
From: "Bruce R. McFarling" <[e-mail]>
Newsgroups: comp.sys.cbm,comp.os.misc,alt.comp.hardware.homebuilt,comp.sys.apple2,comp.sys.apple2.programmer,comp.sys.atari.8bit
Subject: Re: 6502 Multitasking OS announce
Date: 22 Mar 1996 07:28:50 GMT
Organization: Department of Economics, University of Newcastle
Message-ID: <4itkri$[e-mail]>
References: <4i94fs$[e-mail]> <[e-mail]> <4ijtbe$[e-mail]> <4ijuic$[e-mail]> <4innc7$[e-mail]>
NNTP-Posting-Host: econ70.newcastle.edu.au
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.2N (Windows; I; 16bit)

Michael Ellis <[e-mail]> wrote:

>[e-mail] (Ralph Mason) wrote:
>>All well & good BUT the 6502 does not have a relocatable stack pointer
>>so your kinda left with a bit of a problem when it commes to
>>multitasking, ie you cant give each process it's own stack without
>>copying the whole stack ( maybe just to the current sp value? )during
>>each context switch.

>...
>I would consider copying the stack (only the bytes that are actually
>used) during a task switch becase no matter what you do you're going
>to end up copying context-related data at some point.
>
>Consider the case in which zero-page is used to pass parameters.
>When you switch tasks you will HAVE to preserve the context-sensistive
>parameters by copying them to some area of RAM.  This is not unlike
>copying the stack and, using this approach, you can't take advantage of the capabilities that the stack provides (i.e. recusion,
>parameter passing, etc.).

    Here's my reasoning for the two approaches I suggested, that is,
software stacks relying on absolute X-indexed addressing or post-indexed
indirect addressing.

    It's a given that in a time-sliced or other non-cooperative task
switch, the register will be saved. So it makes sense that when the
parameters for a procedure can be held in the registers, simply pass them
in that manner. However, that may not suffice for all procedures.
    Use of stacks was suggested as a way to get around this, and
stacks indeed have all the advantages listed above. There may be problems
using the hardware stack: the limitation in size (256 byte hard limit) is
behind many of them.  However, there are other ways to implement stacks
on the 6502: direct indexing with the index registers permit software
stacks to be implemented that total 256 x the word width in bytes, so for
2 byte stack entries, 512 bytes of software stack space is possible; for
4 byte stack entries, 1024 bytes of software stack space is possible.  No
matter how wide the cells in the stack, by storing each byte of the cell
in its own binary page, 256 cells can be stacked.
    Advantage: a discussed, the index registers will be saved and
restored in any task switch, so after setting a task up with the
appropriate X-value for its segment of the software stack, there is no
additional task-switching overhead. Compared to PHA PLA, there is a loss
of one clock in accessing the stack, but in return it is easier to index
into the stack, to access independent parts of a stack frame.
    Limitations: Fixed 256 cell limit. And, because of the
peculaiarities of X-indexed addressing, to ensure that X and Y are
equally useful as indexes, the stacks must be located within page
boundaries.

    To avoid the fixed limit (other than RAM limits), the only
general indirect addressing modes are (AA,x) and (AA),y, and for handy
access into the stack, (AA),y is superior (though (AA,x) would give the
faster task switch).
    Advantage: 16-bit stack pointer with up to 256 bytes per stack
frame.
    Disadavantage: in addition to the registers, the location
providing the stack address would have to be saved and restored in a task
switch. The accessing is 3 to 5 clocks slower than PHA PLA, depending on
whether a page address boundary is crossed. And the ability to
independently point at two stack entries is lost.

Virtually,

Bruce R. McFarling, Newcastle, NSW
[e-mail]